Current computing systems, and computing system architectures, often employ a host computing system implementing one or more virtual machines, or “Guest Virtual Machines” (GVMs). In a typical implementation of this host and GVM architecture, the host computing system is the physical hardware system and each of the GVMs is a virtual entity created in memory associated with the host computing system. However, in many cases, each GVM behaves, for all practical purposes, as an independent virtual computing system that, in many cases, is capable of implementing/running its own copy of applications and, in some cases, its own operating system. Each GVM also typically has allocated its own memory and controls its own threads and associated memory stacks.
In some implementations of these host and GVM architectures, a special application called a hypervisor is employed through which each of the GVMs is implemented and controlled. Typically the hypervisor controls various GVM operations and the use and access of various hardware systems associated with the host computing system such as, but not limited to: keyboards, mice, various other input and output systems, data storage devices, and any other physical hardware systems associated with the host computing system.
In addition to the hypervisor, some host and GVM architectures include a special virtual machine, called a “Secure Virtual Machine” (SVM). While the SVM is itself a virtual machine run on the host system, unlike a typical GVM, the SVM is “aware” of the fact it is operating in a multiple GVM environment and is provided with special access and control privileges with respect to the other virtual machines, such as the ability to access the other virtual machines, i.e., the GVMs, and their associated memory. In many cases, the SVM is provided its privileged access to the other GVMs via a “hypercall interface” or security Application Program Interface (security API), that allows communication between the hypervisor and SVM and therefore often acts as an extension to the hypervisor.
One example of a currently available security API is VMsafe™ available from VMware™ Inc. of Palo Alto Calif. SVMs and security APIs typically provide a mechanism for changes to be made to, and interactions to be conducted with, individual GVMs without making changes to the hypervisor. This is generally desirable because changes to the hypervisor are often difficult and/or present a security risk. In addition, it is highly desirable to keep the hypervisor as simple/clean as possible.
One way in which SVMs and security APIs are currently used is to inspect/control the access of new/unknown memory pages by the individual GVMs. For instance, in some implementations, when a given GVM page handler determines that a desired page of memory is not present, the new page of memory is requested. The GVM state is then suspended and the new page of memory is then trapped and sent to the SVM for inspection/security analysis prior to resumption of the GVM and use by the GVM.
Traditionally, interactions with a virtual machine, i.e., a GVM, have required the presence of a software agent running in/on the GVM. An agent is typically a program, or other code, responsible for receiving commands, often via a network, and translating them into actions, such as operating system (OS) API function calls. Traditionally, the agent must be either pre-installed in the individual GVMs, or dynamically injected into the GVMs. However, agents are often undesirable, particularly in cases where security and transparency are important requirements, or when the memory footprint created by the presence of the agent is not acceptable.
Despite the problems described above, currently, there is no general, and/or OS-independent technique, for allowing external control of a virtual machine, i.e., a GVM, without the use of an in-GVM agent.
In addition, one disadvantage to the use of SVMs, and the current host/GVM architecture, is that, as noted above, each GVM can be implementing its own applications and Operating System (OS), or versions of a given application or OS, and while the SVM may have access to the GVMs memory, the SVM does not know what application or OS, or version of a given application or OS, is being implemented by the GVM. Therefore, the SVM often does not know the structural content, or context, of the data it can access. This results in what is termed a “semantic gap” whereby the SVM is unable to interpret the internal state of GVMs despite having full access to that state.
As noted above, there is currently no general, and OS-independent, technique for allowing external control of a virtual machine, i.e., a GVM, without the use of an in-GVM agent.